The present invention relates to data networking and, in certain embodiments, to label switching techniques.
Multiprotocol label switching (MPLS) is a network routing technique that operates by appending one or more labels to packets flowing through a network. As the packet encounters successive hops in the network, the label is used to select a next hop and a substitute label. The forwarding mechanism thus consists of a look-up of the incoming label in a table and extraction of the appropriate next hop and substitute label from the table entry. The routing control mechanism essentially consists of appropriately populating such tables in the various nodes in a network.
MPLS supports a very diverse set of services with disparate ways of distributing and selecting labels to accomplish particular objectives. For example, MPLS Traffic Engineering exploits label switching techniques to provide guaranteed bandwidth end-to-end circuits across a network. MPLS can also be used to construct virtual private networks (VPNs) via an IP mesh network. Also, Frame Relay, ATM, or Any Transport over MPLS (AToM) virtual circuits (VCs) may be readily implemented using MPLS. Yet another MPLS service is so-called Fast Reroute (FRR) which can create temporary tunnels around failed links or nodes.
Two or more of these MPLS service scenarios may operate simultaneously at a given point in the network. For example, a service provider may offer a VPN service to a customer having widely separated locations. The service provider's core network is used to link together the locations. VPN traffic between a particular pair of customer locations may flow through one or more MPLS traffic engineering tunnels. Along the way, however, a link or node may fail necessitating the use of MPLS FRR. Each such service will add to the number of labels a packet is carrying. For example, a node that represents the beginning of a traffic engineering tunnel will add a label that will be used to guide the packet to the peer at the other end of the tunnel. That peer will drop the traffic engineering label prior to further forwarding, but other labels may remain. For example, further forwarding after the traffic engineering tunnel may be based on labels distributed to facilitate forwarding within a virtual private network. Thus, instead of a single label, each packet is said to have a label stack with the number of labels varying as the packet traverses nodes which may impose labels, dispose (drop or “pop”) labels, or replace labels. Each node will manipulate one or more of the topmost labels of the label stack while lower level label(s) may remain undisturbed.
A router that incorporates MPLS functionality is referred to as a label switched router (LSR). The LSR typically includes multiple interfaces. A packet traversing the LSR will arrive at an ingress interface. Based on a routing decision made at the ingress interface, an egress interface is selected and the packet is transferred there before being output by the LSR. Accordingly, label forwarding tables are maintained on the ingress interface since that is where an initial decision on the packet's disposition must be taken. A look-up of the packet's incoming label, IP destination address, or other relevant identifier, selection of a next hop and output interface, and label imposition, disposition, and/or replacement all occur on the ingress interface.
It is now desirable to deploy LSRs having very large number of interfaces for use at the edge of service provider networks. A relatively large number of these interfaces, referred to as customer-facing interfaces, will be connected to customer networks while a smaller number, referred to as core-facing interfaces, are connected to the service provider core network. Problems of both scalability and performance, however, arise in performing all label manipulations on the ingress interface, which depending on the direction of the packet may either be the customer-facing interface or the core-facing interface.
Consider, for example, the use of MPLS Traffic Engineering tunnels to carrying customer Layer 2 VPN traffic through a core network. A single provider edge router is connects the core network to a very large number of interfaces to customer VPNs. Whenever a traffic engineering tunnel is added, reconfigured, etc., there will be a change in the label imposed at the edge LSR starting the tunnel. A given tunnel will typically be managed and configured at one of the core-facing interfaces of the edge router or on the linecard including that core-facing interface. However, control plane operations to add, modify, or delete a tunnel may require changes to forwarding tables for numerous core-facing interfaces. Such reconfiguration thus can happen only very slowly. Furthermore, there is a very large amount of label information relating to tunnels that must be stored on each of the numerous customer-facing interfaces.
The Layer 2 VPNs will be managed on the customer-facing interfaces/linecards. But for packets exiting the service provider network, the core-facing interfaces will be the ingress interfaces responsible for label manipulations. Thus each core-facing linecard will have to maintain label information for a potentially very large number of VPNs. Because of the need to handle label manipulations for packets exiting the core network, the core-facing linecards may also have to store label forwarding tables for services such as Layer 3 VPN, AToM, etc. This again impacts scalability.
What is needed are systems and methods for operating label switched routers that can readily accommodate large numbers of interfaces without compromising performance.